ci: run zig build headless, then smoke-test what it installed - #72

Four of the seven images do not ship curl or xz, so four of the seven
squares were red by design. A matrix that is expected to be part red is
a matrix nobody reads. One job now runs all seven and writes the answer
to the step summary, always green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

A passing `zig build` prints nothing, so a green smoke step was
indistinguishable from one that did no work; --summary all makes the
test count visible. timeout-minutes stops a hung step from running
until GitHub's six hour default.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

--summary all prints a ninety line green tree and the failing step's
own output is interleaved thousands of lines above it, so finding out
what broke meant scrolling past every parser that compiled fine.
--summary failures prints only the subtree that failed. The 'what
landed' find dump went with it: it added sixty lines of
lua-language-server paths between the reader and the error, and the
smoke tests report what is missing far more precisely.

Also corrects the note on the alpine row. zls and lua-ls install fine
on musl -- they are tarball extractions. 58 of 59 steps pass there and
neovim's own build is the one that does not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

Both were failing in nvim and nowhere else, but for unrelated reasons,
and only one of them is ours:

  alpine: libuv wants linux/errqueue.h and alpine ships no kernel
  headers by default. linux-headers joins the setup line -- that is
  the documented floor growing, which is what the job is for. The row
  stays experimental because zls and lua-language-server are
  glibc-only, so the smoke tests should now be the next thing to fail.

  ubuntu-24.04-arm: nlua0, the bootstrap lua neovim builds to generate
  its own headers, segfaults on aarch64 linux. Every invocation dies
  with SIGSEGV in gen_declarations.lua. Nothing in this repo is on
  that stack, so the row is experimental rather than fixed, and it is
  kept rather than deleted so it goes green on its own.

Both were invisible before: with --summary all the error was
interleaved thousands of lines above the summary.

Also limits the push trigger to master. With push and pull_request
both unfiltered, every commit on a branch with a PR open built the
entire matrix twice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

alpine passing 8/8 after the linux-headers fix made the gap obvious:
every other binary here is a static zig or rust build, so "the file
exists" and "the file runs on this libc" are the same claim for them
and different claims for lua-language-server, which is the one
dynamically linked thing we install. It was the only check that stopped
at access(), which is precisely where it mattered least.

Running language servers means something can wait on stdin forever if
it does not like its arguments, so expectRun now carries a 60s timeout.
Verified it fires: a 60s sleep comes back as error.Timeout in 2.6s
rather than hanging until the runner gives up.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

7 of 8 smoke tests pass on alpine. Everything builds and everything
runs except lua-language-server, which fails to spawn:

  could not run .../bin/lua-language-server: FileNotFound

A glibc ELF on musl -- execve cannot find its interpreter. It is the
only dynamically linked thing we install, and it is the check that
until this morning stopped at access(), which is why nobody had
noticed either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

Drops the grep. Checked what the guard was buying and it was buying
nothing:

  - getusershell(), which is what every consumer of /etc/shells goes
    through, just enumerates the file. Five duplicate lines iterate as
    five entries with no error, and chsh exits 0 against that file.
    Callers ask 'is this shell in here', which a repeated line answers
    the same way a single one does.

  - the append is not what makes the next line work anyway. chsh only
    consults /etc/shells for non-root callers, and this one is always
    root: setting a shell that appears nowhere in the file succeeds.
    It is there so the file stays honest about which shells are login
    shells, not as a precondition.

So the worst case is a couple of duplicate lines during the window
before $SHELL flips and the step stops running at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

Same job, more lines, no cleverness. The two moving parts are now named
functions -- bootstrap_in and missing_commands -- the image list is one
per line, and the markdown table is assembled once at the end instead of
being appended to from inside the loop.

Fixes a latent bug while it is in there. The old form was

  note="$(printf ... | grep ... | sort -u | paste ...)"
  note="needs: ${note:-see logs}"

and that fallback could never fire: GitHub runs the step under
bash -e -o pipefail, so an image that failed for a reason the grep has
no pattern for made the assignment exit 1 and took the whole step with
it. Verified both halves -- the old form exits 1 without printing the
fallback, the new one reports 'unclear, read the log' and carries on.

The output is also plainer, because the command names are now cut out
of the matches rather than shown raw:

  before   needs: wget: not found xz: Cannot exec
  after    missing: wget xz

Tested against fixtures reproducing each real image's output, plus an
unrecognised failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U73fQ6rCbAPPf1YRHga95Q

ubuntu-24.04-arm and the alpine headless row were both red on purpose
and both blocked on upstream bugs rather than anything here:

  aarch64: neovim's nlua0 build helper dies because lua_newstate()
  returns null for the LuaJIT it is built against. Reported upstream as
  neovim/neovim#40149, open since June with no response.

  alpine: lua-language-server is the one dynamically linked binary we
  install and upstream publishes no musl build, so it cannot spawn.

Removing them takes continue-on-error and the experimental flag with
them, so every remaining square is one that has to be green. alpine
still appears under no-system-compiler, which passes.

Also cuts the comments back to the ones that answer 'why is this
written this way' rather than restating the code.